回想 2025 年初到年中，我大多還是搭配 ChatGPT 和 GitHub Copilot 的自動補全來輔助開發。AI 會幫我想解法、補程式碼，但真正要改哪些檔案、下一步怎麼做，主要還是由我自己決定。那時候 AI 比較像是在旁邊協助，真正動手寫 code 的人仍然是我。
Claude Code 在 2025 年 2 月 24 日先以 limited research preview 推出，到了 5 月 22 日才進入 GA（Generally Available，正式可用）階段。我則是在 6 月 27 日第一次訂閱 Anthropic 的每月 20 美元方案，算起來，那時候 Claude Code 才正式推出一個多月。
不訂閱還好，一訂閱就嚇死人！當時 Claude 模型的 coding 能力，再加上 Claude Code 可以直接搜尋 codebase、修改檔案、執行測試與操作 command line tools，真的彷彿看到漫威電影鋼鐵人中有賈維斯的世界一樣！
才過半個多月，我就因為額度不夠，被迫從 20 美元升級到 100 美元的 Max 方案，正式入坑XD。
開始使用 Claude Code 後，我可以做的事情突然變多了。以前覺得很麻煩、一直放著沒做的想法，好像都可以拿出來試試看。更大的差別是，我不再只是讓 AI 補幾段 code，而是逐漸連 code 都不自己寫了。
這段時間也差不多是 Vibe Coding 一詞開始受到關注的時候。我當時和 AI 協作的方式，其實也很接近「說一個、做一個」。用久之後，我甚至覺得自己好像成了慣老闆：想到一件事就丟給 AI 去做，做完再繼續交代下一件。尤其只是想試一個 idea，或是做個小功能時，常常講幾句話就能看到成果。做完一個，就會忍不住再丟下一個需求給它！
當每個想法都可以先丟給 AI 試試看，我想做的東西也跟著越來越多，AI 產出的 code 自然一起往上增加。有時候甚至一天就會新增、修改好幾萬行 code。這樣的變動速度，早已不是我原本熟悉的開發節奏。
不過，當修改範圍越來越大、對話越來越長，問題也開始慢慢浮現了。我明明說要做 A 功能，做著做著，AI 卻忘記前面談過的方向；有時候我想改的是 A 功能，最後做出來的卻是看起來很像、實際上是不同的 B 功能；也發生過 A 功能改好了，原本正常的其他功能卻跟著壞掉。
這些情況陸陸續續發生後，我才慢慢開始對這種工作方式感到不安。我真的可以只用一句話交代需求，就期待 AI 做出我要的東西嗎？它寫的內容符合團隊規範嗎？一次修改這麼多檔案，我又怎麼知道它沒有順手弄壞其他功能？開發速度確實變快了，但我也開始對眼前的結果感到茫然。
現在回頭看，Leslie Lamport 在〈Why We Should Build Software Like We Build Houses〉中寫過的一句話，剛好說中了我當時缺少的東西：
“Thinking doesn’t guarantee that we won’t make mistakes. But not thinking guarantees that we will.”
思考不能保證我們不會犯錯，但不思考則保證我們一定會犯錯。
Lamport 當時想談的，不只是「寫程式之前記得多想一下」。他希望軟體工程師在開始 coding 前，先理解這個程式到底要做什麼，再透過架構與 specification（規格）把它說清楚。至於規格要寫多細，還是得看功能的大小；小功能可能一兩句 spec 就夠了。真正需要避免的，是還沒有想清楚，就直接開始寫 code，再一路靠著試錯與修 Bug 猜出系統應該長什麼樣子。
以前自己動手寫 code 時，打字、設計與修改本身多少會逼著我停下來思考。AI Agent 把速度加快後，這段停下來確認的過程反而逐漸被我忽略了。問題並不是使用 AI Agent，而是我不應該只丟下一句話，就期待它替我完成後面所有的需求判斷、設計、實作與測試。
而且，就算我在對話裡補了更多需求與背景，這些資訊也不會一直完整留著。如果拿現在許多 Claude 模型都已經來到 1M tokens 的 context window 來看，當時的 200K tokens 好像不算特別大；但放回 2025 年，其實已經很可觀了。只是 Claude Code 在工作時，不只會保留我們的對話，讀進來的檔案、tool call、command 輸出和每一輪回應也會一起占用 context。我又常讓它在同一個需求裡反覆讀取檔案、修改檔案和執行測試，所以 200K 看起來很多，實際跑起來卻消耗得很快，沒多久就會進入 auto compact（自動壓縮）。
壓縮過後，前面談過的細節可能就被簡化；如果再換一個 session，又得重新把需要的資訊帶進去。如果需求只留在對話裡，我和 AI 之間也就少了一個可以共同回頭確認的東西。
而且，後來我才發現，需要共同回頭確認的不只有我和 AI 的對話。隨著開發繼續往前走，團隊原本留下的規格文件，也可能慢慢和最後做出來的 code 對不上。
當時我們團隊在維護專案時，其實也寫了不少規格文件（雖然那些文件不一定是大家熟悉的 PRD 格式XD）。但規格文件寫完後，後面的開發常常沒有繼續和它同步。很多時候都是開始改 code 之後，才發現原本沒有想到的實際問題，當大家討論完，也做了新的決策後，這些新的決策往往只停在當下的討論裡，最後也沒有真的回到規格文件中。
如果開發週期中突然冒出 Bug，情況就更直接了。大家手上都有事情要忙，通常就是先把程式碼打開、直接修正，讓功能恢復正常再說。至於原本的規格要不要一起調整？老實說，多數時候並沒有人回去補這些規格。久而久之，規格記錄的是一開始想做什麼，code 則記錄了最後實際做成什麼，至於中間討論過哪些問題、為什麼改變方向，反而很容易散落在不同地方，甚至只存在某個團隊成員的記憶裡，完全無法追蹤。
那麼，有沒有可能讓規格不要只停在開發開始前，而是跟著整個開發週期一起往前走呢？
這個問題，其實就是 Spec-Driven Development（SDD，規格驅動開發）想處理的事情。在這套方法裡，規格不只是一份開發前的文件，還會繼續參與後面的討論、實作、驗證與修改。
SDD 當然不是 2025 年才出現的，不過到了這一年，已經開始有工具把它直接接進 AI 開發流程。Kiro 在 7 月公開時，已經把 SDD 放進 AI IDE 的核心 workflow；到了 9 月，GitHub 也發表了 Spec Kit。這些工具出現後，SDD 的相關討論也離我的開發工作越來越近。
我自己則是在 2025 年 10 月左右開始接觸 SDD。那時候，要怎麼把 SDD 跟 AI 接在一起，對我來說真的好抽象啊！不過，我也想看看它能不能改善我們團隊當時遇到的問題，所以就這樣踏入了 SDD 的世界。
當時我在 Threads 上看過不少 Spec Kit 跟 OpenSpec 的討論，也沒有先研究每個環節背後的設計。喔～反正都叫做 SDD，那就二選一，先用 Spec Kit 吧！
結果安裝完成後，Claude Code 裡突然多出一整排 commands，也就是用來呼叫不同流程的指令。以前和 AI 協作，通常就是直接說要做什麼；現在卻得先知道要從哪個指令開始，我反而不知道下一步該做什麼了。
簡單看過說明後，我才大概知道這些 commands 的用途與執行順序。看到 Spec Kit 會把需求一路整理成 spec、plan 與 tasks，再讓 AI 依照這些文件實作，我的想法也很直接：結果應該不會差太多吧？這些需求與規格如果可以留下來，也許不只可以跨過 session，開發途中出現的新決策也有機會回到規格裡，不用每次都重新解釋一次。
現在回頭看，只能說：期待越大，失望越大！真的開始跑起來後，我第一個感覺並不是「AI 產生的東西更穩定」，而是：「蛤？怎麼越改越糟？」
文件確實產生了，但每份該寫到多深、規格範圍該怎麼判斷，我還是不知道。老實說，我雖然能照著工具的順序執行，卻連這樣到底算不算在使用 SDD 都說不上來。
所以下一篇，我們就從這個困惑開始，看看 SDD 到底是一套工具、一個固定的 workflow，還是一套不依賴特定工具也能實踐的方法吧！
iThome鐵人賽
看影片追技術